Доработать существующий демон для передачи данных на С языке (Бюджет: 8500 руб, для всех)

1. Исправить существующий демон, который работает не совсем хорошо. При передачи запроса ARP через RAW сокет, для того, чтобы найти MAC адресс соседнего девайса, ARP запрос теряется и второй девайс его не получает. Как должна происходить коммуникация между нодами в mininet:  Клиент отправляет PING запрос к демону через Юникс сокет, демон отправляет ARP broadcast запрос, чтобы найти MAC адресс следующей ноды, получает МАК, записывает его в ARP кеш и отправляет туда МИП запрос с пинг сообщением. Вторая нода получает этот МИП пакет и отправляет ее серверу через юникс сокет, тот возращает PONG сообщение, который проходит через второй демон к первому.  Этот демон будет приложен к заказу Все это реализовано, но надо подправить изначальную отправку и получение ARP сообщение. Второй его почему то не получает После этого нужно доработать и расширить сетевой стек, реализованный на базе протокола Minimal Interconnection Protocol (MIP), для эмуляции связи между узлами в сети, использующей Mininet. На данном этапе необходимо реализовать маршрутизацию и пересылку сообщений между узлами через промежуточные системы с использованием алгоритма маршрутизации Distance Vector Routing (DVR) Основные задачи: Доработка MIP-демона: • Реализовать маршрутизацию и пересылку данных в MIP сети. • Добавить интерфейс взаимодействия с демоном маршрутизации. • Реализовать механизм пересылки MIP-датаграмм через промежуточные узлы (форвардинг). • Добавить поддержку времени жизни (TTL) для сообщений. Реализация демона маршрутизации: Тип SDU (Service Data Unit) для протокола маршрутизации — 0x04 • Демон должен выполнять две основные функции: запуск протокола маршрутизации (DVR) и обработка запросов маршрутов от MIP-демона. • Протокол должен быть динамическим и использовать метод Poisoned Reverse для предотвращения зацикливания маршрутов. • Реализовать сообщения протокола: 1. HELLO — для обнаружения соседей. 2. UPDATE — для рассылки таблицы маршрутов. 3. REQUEST — для запроса маршрута к конкретному узлу. Формат сообщения REQUEST, используемого для запросов маршрутов (от MIP-демона к демону маршрутизации), выглядит следующим образом:   <MIP address of the host itself (8 bits)> <zero (0) TTL (8 bits)> <R (0x52, 8 bits)> <E (0x45, 8 bits)> <Q (0x51, 8 bits)> <MIP address to look up (8 bits)> 4. RESPONSE — для ответа на запрос маршрута. Демон маршрутизации должен отвечать на запросы строго в порядке их получения, используя сообщение RESPONSE со следующим форматом:   <MIP address of the host itself (8 bits)> <zero (0) TTL (8 bits)> <R (0x52, 8 bits)> <S (0x53, 8 bits)> <P (0x50, 8 bits)> <next hop MIP address (8 bits)> Чтобы указать на неудачу при поиске маршрута (нет известного маршрута к запрашиваемому узлу), демон маршрутизации ответит с адресом следующего хопа, равным 255. Изменение Ping-приложений: • Обновить клиент и сервер Ping для работы с новым форматом взаимодействия между MIP-демоном и верхними уровнями, в частности поддержка изменения TTL. Детали реализации: 1. MIP-демон: а. Сокеты: • Демон должен прослушивать RAW-сокет для работы с Ethernet-кадрами. • UNIX-доменный сокет — для взаимодействия с верхними уровнями и демоном маршрутизации. б. Интерфейс с верхними уровнями: • Добавить возможность задания TTL в исходящих сообщениях. • Сообщения через UNIX-сокет должны содержать: MIP-адрес, TTL и полезную нагрузку (SDU). в. Форвардинг: • Если сообщение предназначено не для текущего узла, его TTL уменьшается, и запрос отправляется демону маршрутизации для поиска следующего хопа. • Если маршрут найден, сообщение пересылается следующему узлу с обновленным TTL. • Если маршрута нет или TTL достигает 0, сообщение отбрасывается. 2. Демон маршрутизации: а. Интерфейс взаимодействия с MIP-демоном через UNIX-доменный сокет. б. Протокол маршрутизации: • Реализовать Distance Vector Routing (DVR) с защитой от зацикливания с помощью Poisoned Reverse. • Обновления таблицы маршрутов и обработка запросов на маршрутизацию должны быть асинхронными, чтобы не блокировать работу MIP-демона. в. Форматы сообщений: • REQUEST: Запрос маршрута должен включать MIP-адрес отправителя и адрес искомого узла. • RESPONSE: Ответ на запрос маршрута должен содержать MIP-адрес следующего хопа или 255, если маршрут не найден. 3. Ping-клиент и сервер: o Обновить взаимодействие с MIP-демоном через UNIX-сокет для поддержки нового формата сообщений с TTL. Требования к реализации: 1. Язык программирования: C 2. Среда разработки: Виртуальная машина с Mininet. 3. Сетевой стек: Использование MIP протокола для передачи данных. 4. Маршрутизация: Алгоритм Distance Vector Routing с механизмом Poisoned Reverse.